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EFFICIENT ERROR CONTROL FOR FIG. 2 shows the poor throughput performance of packet 

WIRELESS PACKET TRANSMISSIONS data transmissions using a stop and wait protocol for an 

exemplary transmission scenario 59 when there are errors in 

FIELD OF THE INVENTION the transmission of one or more frames. In FIG. 2, like FIG. 

The field of this invention pertains to 5 h the first frame, or data sequence, 60 is successfully 

telecommunications, including a telecommunications sys- transmitted and an acknowledge message add 62 is sent in 

tern that includes efficient error control for packet transmis- £ s P ons ^ however, in transmission scenario 59, the second 

s - ons frame 64 is uiisuccessnilly transmitted, and a negative 

acknowledge ("nack") message nack2 6 6 is sent in response . 

DESCRIPTION OF THE TECHNOLOGY 10 Receipt of the nack2 66 triggers the entity transmitting the 

„ „ , . , packet data to transmit the second frame a second time 

Generally, known commumcation systems provide trans- (message 68). On the second attempt, the second frame 68 

mission error correction of packet data, i.e., messages trans- ^ success fui ly transmitted and an acknowledge message 

mitted in a packetized format, through the use of standard ack2 70 is sent in response. However, because the initial 

automatic repeat request ("ARQ") mechanisms, also known transmission of the second frame 64 was unsuccessful, it has 

as backward error correction mechanisms. In wireline 15 ta k eil three time frames 140 to successfully transmit two 

systems, ARQ mechanisms are thought to be fairly effective, frames of data. 

as, generally, wireline channels experience relatively low Further, in FIG. 2, while the third frame 72 is successfully 
transmission error rates. transmitted, with an acknowledge message ack3 74 sent in 
In wireless networks, or systems, however, the radio response, the fourth frame 76 is unsuccessfully transmitted, 
channel, or over-the-air interface, is characterized by a 20 with a negative acknowledge message nack4 78 sent in 
considerably elevated transmission error rate compared to a response. Receipt of the nack4 78 triggers the entity trans- 
wireline channel. This, in turn, tends to reduce the effec- mitting the packet data to transmit the fourth frame a second 
tiveness of standard ARQ mechanisms, as the probability of dme (message 80). On the second attempt in exemplary 
ever successfully transmitting a frame, i.e., a portion of traffic .«»?™ 59 > *™? h frame 80 » successfully 
packet data, also referred to as a data segment, error free * transmitted ^and an acknowledge message ack4 82 is sent in 

may be very low. The overall impact may be either a serious £ s P on £ ^ 1™ ISS10D of 

/ .. . . # « , t , / ■ j i frame 64 and the fourth frame 76 were unsuccessful, it has 

reduction m system throughput and an increase in delay, or, tl . r. 1jin * c « , c 

f „ „ / ,f r J9 ' taken six time frames 140 to successfully transmit four 

possibly, total system collapse. frames of daU 

Known systems employing transmission error control In the same scenario 59> the fiftn fr ame 84 is unsuccess- 
also may provide a cyclic redundancy code («CRC) for m transmitted on the first attempt, and a negative 
error detection. Generally, a cyclic redundancy code is a type acknowledge message nackS 86 is sent in response. Receipt 
of frame check sequence computed by treating data bit of ^ nack5 86 ^ receipt of the other negative acknowl . 
strmgs as polynomials with binary coefficients, and perform- edge mesS ages, triggers the entity transmitting the packet 
ing a mathematical calculation thereon. ACRC, therefore, is data to retransimt the fifth frame a second time (message' 
basically a code that is transmitted along with a frame, or 88) 0n me second attempt m 59j ^ fift h 88 
data segment, to enable the receiver to detect data corrup- ^ success rully transmitted and an acknowledge message 
tl0D * ack5 90 is sent in response. However, as the initial trans- 
Known systems employing transmission error control mission of the second frame 64, the fourth frame 76 and the 
also generally provide a mechanism for signaling failures, ^ fifth frame 84 were unsuccessful, it has taken eight time 
which are used to trigger retransmissions. Most known data frames 140 to successfully transmit five frames of data, 
system retransmission policies fall into one of the two Xhe sixth framc 92 0 f scenario 59 is successfully 
following categories. transmitted, and an acknowledge message ack6 94 is sent in 
The first known retransmission category is a "stop and response. The seventh frame 96, however, is unsuccessfully 
wait" protocol. In a stop and wait protocol, each frame must 45 transmitted, and a negative acknowledge message nack7 98 
be explicidy acknowledged before the next can be sent. is sent in response. Upon receiving the nack7 98, the entity 
As shown in FIG. 1, wherein a stop and wait protocol is transmitting the packet data transmits the seventh frame 
employed in an exemplary transmission sequence 1, an once again (message 100). On the second attempt in scenario 
acknowledge ("ack") message is sent in response to every 59, the seventh frame 100 is successfully transmitted and an 
successful frame transmission. Thus, ackl message 10 is 50 acknowledge message ack7 102 is sent in response, 
transmitted in response to the successful receipt of frame 5, However, it has now taken eleven time frames to success- 
ack2 message 20 is transmitted in response to the successful fully transmit only seven frames of data, 
receipt of frame 15, ack3 message 30 is transmitted in The eighth frame 104 and the ninth frame 108 are both 
response to the successful receipt of frame 25, and so on. successfully transmitted on the first attempt in scenario 59, 
FIG. 1, depicting successful transmission conditions, ss with an acknowledge message ack8 106 and ack9 110 
shows that even under favorable conditions, with a stop and respectively sent in response. However, the initial transmis- 
wait protocol the data transmission throughput is generally sion of the tenth frame 112 is unsuccessful, and a negative 
poor. Only one data frame is generally transmitted per time acknowledge message nacklO 114 is sent in response. Upon 
frame 50. Too, an acknowledge message must be sent in receipt of the nacklO 114, the entity transmitting the packet 
each time frame, in response to the data transmission in that 60 data transmits the tenth frame again (message 116), in the 
time frame, causing additional message traffic on what may subsequent time frame. On the second attempt, the tenth 
already be a scarce resource. frame 116 is successfully transmitted and an acknowledge 
Thus, using a stop and wait protocol, it can take fifteen message acklO 118 is sent in response. However, it has taken 
time frames to transmit a packet data segmented into fifteen fifteen time frames to successfully send just ten frames of 
frames. And the transmission sequence 1 is shown under 65 data. 

favorable transmission conditions, i.e., all data transmis- In traffic scenario 59, the remaining five frames 120, 124, 

sions are successful on the first attempt. 128, 132 and 136 of the packet data are successfully 
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transmitted on the first attempt, with respective acknowl- of the second group of five frames of data 220, as well as the 

edge messages 122, 126, 130, 134 and 138 sent in response. entire first group of five frames of data 205. 

With a stop and wait protocol, where several frame The ack3 message 240 is responsive to the successful 

transmissions are unsuccessfully transmitted on an initial transmission of the third group of five frames of data 235 in 

attempt, several additional transmissions and a significantly 5 time frame 245. The ack3 message 240 acknowledges the 

longer time to successfully transmit the entire packet data successful transmission of the fifteenth frame 214, and, 

results. Specifically, as well as frames 64, 76, 84, 96 and 112 thereby, also acknowledges the successful transmission of 

of scenario 59 requiring subsequent retransmission, five the preceding frames 216, 217, 218 and 219 of the third 

negative acknowledge messages are transmitted and five group of five frames of data 235, as well as the first group 

additional acknowledgment messages are also transmitted. io of five frames of data 205 and the second group of five 

Also, in scenario 59, twenty time frames are required to frames of data 220. 

transmit fifteen frames of data. i n scenario 201, fifteen frames of packet data are sue- 
Thus, with a stop and wait protocol, as the data transmis- cessfully transmitted in three time frames. However, under 
sion error rate increases, the additional message transmis- less favorable conditions, as are generally expected on a 
sion count and the delay in finalizing transmission of data 15 wireless interface, the inadequacies of a window protocol 
packets also increases. Use of stop and wait protocols, become apparent. 

therefore, generally results in poor transmission throughput Referring to FIG. 4, a window protocol in which error 

performance under the best of conditions, which is only transmissions are discovered by the lack of acknowledge - 

further degraded as transmission conditions degenerate. ment is depicted in exemplary traffic scenario 269 which 

Also with a stop and wait protocol, generally not more 20 includes data transmission errors. In scenario 269, a first 

than one or two frames of data of a packet data can be sent group of five frames of data 304 is transmitted in time frame 

in a time frame. This provides simplicity of implementation 270. However, the second frame 276, the fourth frame 278, 

and operation. It is also the result of timing issues involved and the fifth frame 279 in group 304 are unsuccessfully 

in successfully receiving a frame and processing an transmitted. Thus, the receiving entity only acknowledges 

acknowledge message response, or alternatively, realizing 25 the successful transmission of the first frame 275, with acid 

that a frame that should have been transmitted has not been message 280. 

received, and processing a negative acknowledge response. As the acknowledge messages in a window protocol in 

This limitation, however, limits packet data throughput and which error transmissions are discovered by the lack of 

reduces the flexibility of the transmission system. ^ acknowledgement acknowledge the last sequential frame in 

Too, the use of a stop and wait protocol requires that a packet data to be successfully transmitted, the ackl mes- 

frames of packet data be transmitted sequentially, e.g., for sage 280 only acknowledges the first frame 275. Although 

example, a third frame of a packet data can not be trans- the third frame 277 was also successfully transmitted, the 

mitted prior to the transmission of the first and second second frame 276 was not, and thus, the third frame 277 is 

frames. This limitation, in turn, reduces the flexibility of the 35 not acknowledged as it is not the last sequential frame to be 

transmission system. successfully transmitted. 

The other known retransmission category is a "window" In scenario 269, a second group of five frames of data 305 

protocol. In a window protocol, a number of transmitted is transmitted in a second time frame 271. The second group 

frames can be outstanding, i.e., unacknowledged, and trans- of five frames of data 305 is comprised of the second 

mission errors can be discovered by the lack of ^ through sixth frames (281-285), as these are the subsequent 

acknowledgement, which generally triggers a "go back N" sequential frames after the only acknowledged first frame 

frames and retransmit response. Alternatively, transmission 275. In scenario 269, all five frames of data 305 of the 

errors may be discovered by the receipt of a selective reject second group are successfully transmitted. Thus, the receiv- 

mechanism, which generally triggers selective retransmis- ing entity transmits an ack2 message 286 acknowledging the 

sion of the indicated missing frame. 45 successful transmission of the sixth frame 285. The ack2 

As shown in the exemplary transmission scenario 201 of message 286 thereby also acknowledges the successful 

FIG. 3, wherein a window protocol is employed, more than transmission of the other four frames transmitted in time 

one frame of packet data may be sent in a time frame and one frame 271, i.e., frames 281-284. The ack2 message 286 

acknowledge message is used to acknowledge the successful further acknowledges the previous successful transmission 

transmission of the sequential frames successfully transmit- 50 of the first frame 275. 

ted- A third group of five frames of data 306 is transmitted in 

Scenario 201 depicts a transmission scenario under favor- a third time frame 272. The third group of five frames of data 

able conditions; i.e., each frame of data in the packet data is 306 is comprised of the seventh through eleventh frames 

successfully transmitted, and received, on a first attempt. (287-291), as these are the subsequent sequential frames 

Thus, ackl message 210 is sent in response to the successful 55 after the acknowledged sixth frame 285. In scenario 269, the 

transmission of a first group of five frames of data 205 in seventh frame 287 and the tenth frame 290 are unsuccess- 

time frame 215. The ackl message 210 acknowledges the fully transmitted. Thus, the receiving entity only acknowl- 

successful transmission of the fifth frame 202, and, thereby, edges the successful transmission of the preceding sixth 

also acknowledges the successful transmission of all pre- frame 285 with the ack3 message 292. 

ceding frames (203, 204, 206 and 207) of the first, group of eo As the acknowledge messages in a window protocol in 

five frames of data 205. which error transmissions are discovered by the lack of 

In scenario 201, the ack2 message 225 is sent in response acknowledgement acknowledge the last sequential frame in 

to the successful transmission of the entire second group of a packet data to be successfully transmitted, the ack3 mes- 

five frames of data 220 in time frame 230. The ack2 message sage 292 acknowledges the sixth frame 285. Although the 

225 acknowledges the successful transmission of the tenth 65 eighth frame 288, the ninth frame 289 and the eleventh 

frame 208, and, thereby, also acknowledges the successful frame 291 were also successfully transmitted, the seventh 

transmission of the preceding frames 209, 211, 212 and 213 frame 287 was not. Thus, the eighth frame 288, the ninth 
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frame 289 and the eleventh frame 291 are not acknowledged The third group 331 of five frames of data comprises the 

in time frame 272 as none of these frames are the last second through sixth frames (332-336 respectively). The 

sequential frame to be successfully transmitted at the time. transmitting entity sends a fourth group 337 of five frames 

In scenario 269, a fourth group of five frames of data 307 of data in a fourth time frame 317. The fourth group 337 of 

is transmitted in a fourth time frame 273. The fourth group 5 five frames of data comprises the seventh through eleventh 

of five frames of data 307 is comprised of the seventh frames (338-342 respectively). 

through eleventh frames (293-297), as these are the subse- In scenario 310, similar to scenario 269 of FIG. 4, the 

quent sequential frames after the last acknowledged sixth seventh frame 338 and the tenth frame 341 are unsuccess- 

frame 285. In scenario 269, all five frames of data 307 of the fully transmitted on the first transmission attempt Thus, the 

fourth group are successfully transmitted. Thus, the receiv- 10 receiving entity acknowledges only up to the sixth sequen- 

ing entity transmits an ack4 message 298 acknowledging the tial frame 336. The ack2 message 343 acknowledges the 

successful transmission of the eleventh frame 297. The ack4 successful transmission of the sixth frame 336, thereby also 

message 298 thereby also acknowledges the successful acknowledging the successful transmission of the first 

transmission of the seventh, eighth, ninth and tenth frames through fifth frames (320 and 332-335 respectively). 

(293-296 respectively), as well as the first through sixth The transmitting entity thereafter sends a fifth group 344 

frames (275 and 281-285 respectively). 15 0 f five frames of data in a fifth time frame 318, The fifth 

A fifth group of frames of data 308 is transmit ted in a fifth group 344 of five frames of data comprises the seventh 
time frame 274. The fifth group of frames of data 308 is through eleventh frames (345-349 respectively). The trans- 
comprised of the twelfth through fifteenth frames (299-302) mitting entity sends a sixth group 390 of frames of data in 
of the packet data, as these are the subsequent sequential ^ a sixth time frame 319. The sixth group 390 of frames of 
frames after the acknowledged eleventh frame 297. The fifth data comprises the twelfth through fifteenth frames 
group of frames of data 308 is comprised of only four frames (385-388 respectively). The sixth group of frames of data 
in scenario 269 as there are only four remaining frames in 390 is comprised of only four frames in scenario 310 as there 
the packet data of fifteen frames to be transmitted at the time. are only four remaining frames in the packet data of fifteen 

In scenario 269, all four frames of data of the fifth group ^ frames to be transmitted at the time. 

308 are successfully transmitted. Thus, the receiving entity In scenario 310, all five frames of data 344 of the fifth 

transmits an ack5 message 303 acknowledging the success- group are successfully transmitted and all four frames of 

ful transmission of the fifteenth frame 302. The ack5 mes- data 390 of the sixth group are also successfully transmitted, 

sage 303 thereby also acknowledges the successful trans- Thus, the receiving entity transmits an ack3 message 389 

mission of the first fourteen frames of data (275, 281-285, 3Q acknowledging the successful transmission of the fifteenth 

293-297 and 299-301 respectively). frame 388. The ack3 message 389 thereby also acknowl- 

Employing a window protocol with lack of an acknowl- edges the successful transmission of the first fourteen frames 

edge response triggering retransmission results in success- of data (320, 332-336, 345-349 and 385-387 respectively), 

fully transmitted frames being retransmitted, consuming As can be seen in scenario 310, using this window 

valuable resources. Thus, while not shown in exemplary 35 protocol has required six time frames to successfully 

scenario 269, a frame which was successfully transmitted a transmit, and acknowledge receipt thereof, packet data of 

first time may be unsuccessfully transmitted a second time, fifteen frames. Moreover, as with the previous window 

triggering repeated transmissions of the same frames. Also, protocol message scenario 269, in scenario 310 successfully 

as with the stop and wait protocol, the window protocol with transmitted messages are required to be retransmitted, 

lack of an acknowledgement response triggering retransmis- ^ Thus, the larger the window in this window protocol, the 

sion requires that frames of packet data be transmitted more time which will generally be necessary to successfully 

sequentially, e.g., for example, a third frame of a packet data transmit and acknowledge packet data. On the other hand, 

can not be transmitted prior to the transmission of the first with this window protocol and a smaller window, even more 

and second frames. This limitation generally reduces the time is generally required to transmit packet data. Further, if 

flexibility of the transmission system. 45 the window is made small enough, i.e., a one frame window, 

Additionally, as the window, i.e., frames of data trans- the resultant protocol will generally be similar to the wait 

mitted between acknowledgements, in a window protocol and see protocol previously discussed. In this case, the only 

with lack of acknowledgement response triggering retrans- difference between the two protocols would be that, instead 

mission is increased the window protocol will generally of receiving a negative acknowledge message if the previous 

require still more successfully transmitted frames to be 50 frame is transmitted in error, as with the wait and see 

retransmitted. This can result in an increased burden on what protocol, an acknowledge message indicating the last 

may generally be scarce resources. sequential successfully transmitted frame is transmitted in 

For example, referring to exemplary scenario 310 in FIG. the window protocol. 
5, acknowledgement messages are sent only every second Referring to FIG. 6, exemplary traffic scenario 380 uses a 
time frame. Assuming, as with scenario 269 in FIG. 4, that 55 window protocol in which error transmissions are selec- 
tive frames of data are transmitted per time frame, a first tively rejected. In scenario 380, five frames of packet data 
group 311 of the first five frames of packet data is trans- are transmitted per time frame, and transmission errors do 
mitted in time frame 314 and a second group 312 of the occur. A first group 382 of five frames of data is transmitted 
second five frames is transmitted in time frame 315. In in a first time frame 350 of scenario 380. In this scenario 
scenario 310, similar to scenario 269 of FIG. 4, the second eo 380, the second frame 351, the fourth frame 352, and the 
frame 321, the fourth frame 323 and the fifth frame 324 are fifth frame 353 in group 382 are all unsuccessfully trans- 
unsuccessfully transmitted on the first transmission attempt. mitted on the first transmission attempt. The receiving entity, 
Thus, the receiving entity only acknowledges the successful therefore, sends a negative acknowledge message nack2 
transmission of the first frame 320 with the ackl message 354, selectively rejecting the frame of data 351 (frame two) 
330. 65 first transmitted in error. 

In scenario 310, the transmitting entity then sends a third In response to the nack2 354, the packet data transmitting 

group 331 of five frames of data in a third time frame 316. entity transmits frame two of the packet data a second time 
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(message 356), in a second time frame 355. In time frame As previously indicated, a problem with known window 

355, the packet data transmitting entity also transmits the protocols is that the associated state machines for imple- 

sixth, seventh, eighth and ninth frames, thereby transmitting mentiog them in a system are generally quite complex. With 

a total of five frames of data in time frame 355. window protocols, both the receiving and transmitting sides 

As in prior exemplary scenarios, the seventh frame 357 is 5 must store send and receive packet sequence numbers and 

transmitted in error. However, at this time, the receiving nex t expected packet sequence numbers, and both sides 

entity sends a negative acknowledge message nack4 358, mus t have the capability to signal to negotiate the window 

selectively rejecting frame four 352 of data that was the size and other relevant parameters. Further, large amounts of 

second frame previously transmitted in error, in time frame data may nccd to be buffered at both sides (transmitting and 

10 receiving) in a window protocol scheme, requiring increased 

In response to the nack4 358, the packet data transmitting mcm0 ry usage and maintenance. Large amounts of data are 

entity transmits frame four of the packet data a serand toe not gcncrally required to be buffered in a wait and see 

message 359 , m a third time frame 360 In time frame 360, q{ How „ previous i y discussed, with a wait and 

the packet data trar^mi tmg ^ ocq1 tosmission throughput is gencrai]y 1^ 

eleventh, twelfth and thirteenth frames of data, thereby a- • . • « • ■ 1 ; 

transmitung a total of five frames of data in time frame 360 15 cffic,ent ' «P«aUy ™ a ™ek» 

As in prior exemplary scenarios, the tenth frame 361 is The P roblems with st0 P and wait Protocols and window 

transmitted in error. However, the receiving entity sends a Protocols are generally particularly acute in wireless 

negative acknowledge message nack5 362, selectively systems, due to the scarcity of radio resources, 

rejecting frame five 353 of data that was the third frame Thus, it would be advantageous to provide an error 

previously transmitted in error, in the first time frame 350. 20 control mechanism for use in a wireless packet data system 

In response to the nackS 362, the packet data transmission mat improves performance when compared to existing error 
entity transmits frame five of the packet data a second time correction schemes. Specifically, it is advantageous to pro- 
message 363), in a fourth time frame 365. In time frame Vlde an error control mechanism that minimizes the com- 
365, the packet data transmission entity also transmits the _ plexity of the system generally required in schemes employ- 
final two frames of the packet data. Although all three m Z window protocols, while providing better performance 
frames of data are successfully transmitted in time frame ^ n sun P le wait and schemes. It is also advantageous to 
365, the receiving entity sends a negative acknowledge P rovide m error CODtro1 mechanism that limits the number 
message nack7 364 response, indicating that frame seven of messages required for error transmission detection and 
357 of data was the fourth frame previously unsuccessfully „ correction. Further, it is advantageous to provide an error 
transmitted, in the time frame 355. 00111101 mechanism that can be used in low cost terminals 

Upon receiving the nack? 364, the packet data transmit- wmle P^vMing performance than schemes employ- 

ting entity transmits frame seven of the packet data a second m ^ 31 10 P ro 00 s * 

time (message 366), in a fifth time frame 370. As the entity SUMMARY OF THE INVENTION 

transmitting the packet data is unaware of any other frames 35 . . . 

requiring transmission, it transmits no other frames of data Th c inventions provide methods and mechanisms for 

in time frame 370. error control in a communication system where a group of 

Transmission of frame seven 366 in time frame 370 is more man onc mcssa S c ^transmitted by one entity, ie., a 
successful in scenario 380. However, the receiving entity transmitung entity, either in the communication system or 
sends a negative acknowledge message nacklO 367 in time 40 bnkcd thcrcto > to a sec . ond entlt ^ l *- a reccivm S cntlt ^ also 
frame 370, indicating the prior unsuccessful transmission of either m the communication system or linked thereto, 
frame ten 361 of data, the fifth frame previously unsuccess- In a presently preferred embodiment, a transmitting entity 
fully transmitted, in the time frame 360. In response, in the transmits a group of more than one user message, e.g., 
following time frame 375, the packet data transmitting entity frames of packet data, to a receiving entity. The receiving 
transmits frame ten of the packet data a second time 45 entity, for its part, generates a responsive message to trans- 
message 368). The second transmission of frame ten 368 is mit in response to the transmission of the group of messages, 
successful, and the receiving entity thereafter acknowledges The responsive message indicates each message in the group 
successful transmission of the packet data by sending an of messages that was successfully transmitted to the receiv- 
acknowledge message ackl 369 in time frame 375. ing entity, if any. Thus, the responsive message is also 

No frames of data are unnecessarily retransmitted with a 50 mdicative of each message in the group of messages that was 

window protocol with selective retransmission. However, in unsuccessfully transmitted to the receiving entity, if any. 

a typical scenario 380, it required six time frames to transmit A£txx generating the responsive message, the receiving 

fifteen frames of data. Moreover, a negative acknowledge entit y transmits it to the transmitting entity 

message is required for each frame of data unsuccessfully The transmitting entity, upon receiving the responsive 

transmitted. Thus, the more errors on the transmission 55 message, determines which, if any, of the group of messages 

channel, the more negative acknowledge messages, and was successfully transmitted to the receiving entity. The 

thus, the more control message traffic that is required to transmitting entity does not retransmit any of these success- 

successfully complete a packet data transmission. fully transmitted messages. 

Aproblem with known window protocols is that frames of The transmitting entity also determines from the respon- 
data are often unnecessarily retransmitted and/or additional 60 sive message which, if any, of the group of messages was 
time frames are required to successfully transmit the packet unsuccessfully transmitted to the receiving entity. The trans- 
data. Thus, although the window protocols are more efficient mitring entity thereafter retransmits each of the messages 
for packet data transmissions than the wait and see protocol, that was previously unsuccessfully transmitted, 
they are also more complex, requiring additional processing Thus, in a presently preferred embodiment, a responsive 
by those entities employing them. In addition, the window 65 message is indicative of the unsuccessful transmission of 
protocols are still not generally efficient enough to handle one or more specific messages of a group of transmitted 
error processing in a wireless transmission environment. messages. This provides for the retransmission of only those 
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messages of the group of messages that were previously In a presently preferred embodiment, allocation of 

unsuccessfully transmitted. physical, over-the-air, Le., radio, or wireless, resources to a 

A general object of the inventions is to provide a trans- packet data user of a wireless communication system is 

mission error control method and mechanism that allows for asymmetric. As an example, in one embodiment, five time 

increased throughput of transmission traffic by reducing the 5 s l Qts °f a ^ mc frame are allocated to carry frames of packet 

overhead, i.e., control message, traffic required for transmis- data m the forward, i.e., transmission, direction. Further, at 

sion error control. A further general object of the inventions lcast ? nc timeslot of each time frame in which the packet 

is to provide an error control method and mechanism that data is transmitted is allocated in the return direction, to 

minimizes the complexity of a system managing transmis- transmit acknowledgments of the packet data frames. In a 

sions between various entities. Other and further objects, 1° presently preferred embodiment, one time slot per time 

features, aspects and advantages of the inventions will frame is allocated in the return direction for each packet data 

become better understood with the following detailed transmission, regardless of the number of time slots allo- 

description of the accompanying drawings. cate ^ in the forward direction. 

In a presently preferred embodiment, the window size, 

BRIEF DESCRIPTION OF THE DRAWINGS is i <e<j the number of messages transmitted as a group, or, more 

FIG. 1 is an exemplary traffic scenario using a wait and specifically, the number of frames of data, or data segments, 

see protocol, where there are no errors in transmission. or ^ messages, of packet data transmitted in a time frame, 

FIG. 2 is an exemplary traffic scenario using a wait and * det ^nined during the execution of a resource allocation 

see protocol, where there are transmission errok M P^ure, before data transmission. In a presendy preferred 

„ . , ^ . . . 20 embodiment, the maximum transmit window size for the 

* aQ e f mplary tiaffiC SCenan ° ^ " Wmd0W P^ket data is negotiated for, and defined, during the pro- 
protocol, where there are no errors in transmission. of a transmission resource allocation procedure, and 

FIG. 4 is an exemplary traffic scenario using a window resources for the acknowledgments are allocated to cater to 

protocol, with no acknowledgement indicating errors, where the determined window size. For example, if a maximum 

there are transmission errors. 25 window size of five is defined, the receiving entity will 

FIG. 5 is another exemplary traffic scenario using a acknowledge the data segment transmissions in groups of 

window protocol, with no acknowledgement indicating five; i.e., the receiving entity will transmit an aggregated 

errors, where there are transmission errors. acknowledgment message for the possible transmission of 

FIG. 6 is an exemplary traffic scenario using a window everv five <kta segment transmissions. In this example, at 

protocol with a selective reject mechanism, where there are 30 least one-fifth of the resource allocated for the packet 

transmission errors. transmission direction must be allocated to the aggregated 

FIG. 7 is an embodiment of an aggregated acknowledge acknowledgement direction, 

message m a presently preferred embodiment, packet data can 

FIG. 8 is an exemplary traffic scenario using an aggre- 35 P° le f ^ be as lo ? fifteen hundred (1500) bytes, and is, 

gated acknowledge message mechanism for error control, ^ refore > «*> ">«U« called frames or 

where there are no errors in transmission. data h » V™*** preferred embodiment, each 

™™ „. OT1 jor> 1 . • * * frame, or data segment, of packet data (or just "packet") is 

FIGS. 9A, 9B and 9C are exemplary aggregated acknowl- Dineteen of fc m Qne hundfed ^ fift ^ 

edgment messages for the traffic scenario of FIG. 8. ^ Jong ^ a packet of fifteeQ hundred ^ £ ^ 

FIG. 10 is an exemplary traffic scenario using an aggre- <0 meatti mt0 seventy-nine (79) data segments, 
gated acknowledge message mechanism for error control, ^ & a fwred embodimem Mch da , a s , 

where there are transmission errors. . . . . 4 „ r 

™„ « \« JrZ7^ * has a sequence number associated with it, to allow for 

FIGS. 11A, UB, 11C and 11D are exemplary aggregated ^assembly otiht packet at a receiv i n g en d. Among 

acknowledgement messages for the traffic scenario of FIG. ^ olher hene&% ^ ai lows for data segments to be transmit- 

ted out of order. 

^J 5 m ^ sec 1 0I l d exemplary traffic scenario using an In a Q ferrcd cmbodiment , m aggrcga ted 

aggregated acknowledge mechanism for error control, acknowledgement message ("AACK message") is transmit- 

where there are transmission errors. ted by the receiving end of a wire i eS s transmission path. The 

FIG. 13 illustrates a general embodiment of a packet data 5Q aack message contains a bit map which identifies all the 

services network. da t a segments of the packet data which have been success- 

FIGS. 14A, 14B and 14C depict various different embodi- fully transmitted up to when the AACK message is sent, 

ments of a mobile end station. including data segments that have been previously acknowl- 

FIG. 15 illustrates an embodiment of a protocol stack for edged. The AACK message also, by default, identifies the 

a mobile end station and an embodiment of a protocol stack 55 data segments that have been unsuccessfully transmitted up 

for a base station subsystem. to when the AACK message is sent This format allows 

multiple data segments to be acknowledged ("Acked"), or 

DESCRIPTION OF THE PREFERRED negative acknowledged ("Nacked"), together. As in the 

EMBODIMENTS presendy preferred embodiment there is a maximum of 

In the following description, for purposes of explanation, 60 seventy-nine data segments per packet, the AACK message 

numerous specific details are set forth in order to provide a has seventy-nine bits to status all possible data segments in 

thorough understanding of the invention. It will be apparent, one packet. 

however, to one skilled in the art, that the invention may be Referring to FIG. 7, a presendy preferred embodiment of 

practiced without these specific details. In other instances, an AACK message 400 is depicted, wherein the AACK 

well-known structures, devices or protocols are shown in 65 message 400 is twenty octets, or bytes, in length. The first 

block diagram form to avoid unnecessarily obscuring the octet 405 of the AACK message 400 is an eight-bit field for 

invention. the message type, or identification. The message type field 
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of the AACK message 400 indicates that the message is an circumstances, an AACK message is transmitted with an 

AACK message. The next ten octets 410 of the AACK acknowledgement for one or more out of sequence data 

message 400 contain a bit map which contains an A/N bit for segments. For example, data segment number ten may be 

each of a possible seventy-nine data segments, with bit eight acknowledged while data segment number nine is not. 

°/^ Ct u.l eleV ^ n b ^ g u' Spare ' bU * ™ e *° cation of ™ 5 In a first, presently preferred embodiment, event, if a data 

Am bit within the bit map is mdicative of the sequence or f fa acknowkd d out of t the unac . 

number of the respective data segment of the packet which ^ M d data 0 r frames, are retransmitted 

the bit is used to acknowledge as successfully received. n Tu j . . I j* J. . ~ j 

Tims, for example, A/N bit 430, which is the first A/N bit "?* f ^ SQ ^f °J a P acke 316 traDSmi ted 

in the bit map of the AACK message 400, is the A/N bit for , n f east °?«*> l « For example, an exemplary 

acknowledging the successful transmission of the first data 10 da | a P acket ^ feen Barnes and frame number ten is 

segment of a packet. A/N bit 431, which is the second A/N acknowledged before frame number nine. Frames eleven 

bit in the bit map of the AACK message 400, is the A/N bit fo° a & M teen m transmitted after frame ten is acknowl- 

for acknowledging the successful transmission of a second edged. Then, frame nine is retransmitted, 

data segment of the packet, and so on. A/N bit 432, which In this first embodiment event, the receipt of an aggre- 

is the seventy-ninth, and final, A/N bit in the bit map of the 15 gated acknowledgement of data frame nine does not trigger 

AACK message 400, is the A/N bit for acknowledging the retransmission of data frames ten or eleven through fifteen, 

successful transmission of a seventy-ninth data segment of This is because the successful transmissions of data frames 

a packet. Thus, the AACK message 400 is formatted such ten through fifteen have already been previously acknowl- 

that a maximum of seventy-nine possible outstanding data edged; the respective bits in the aggregated acknowledge 

segments of a packet can be acknowledged with a single 20 messages have been set, and remain set, to indicate these 

message. The AACK message 400 format, therefore, pro- frames' successful receipt by the receiving entity, 

vides for all potential segments of a fifteen hundred (1500) , n a eveaty if a daU m? 0f fr fc acknowl . 

byte packet to be acknowledged with one AACK message. edged out of tum> me unackDOwledged data segments), or 

In a presently preferred embodiment, each A/N bit is set frames> m retransmitted in the time frame following the 

to a value of zero if a corresponding numbered data segment 25 dmc frame ^ which me entity reccivcs me 

has not be transmitted or has been transmitted in error. Each aggregated acknowledgement indicating one or more data 

A/N bit is set to a value of one if the corresponding segments were not transmitted correctly. For example, an 

numbered data segment has been transmitted, and received, exemplary data packet has fifteen frames and frame number 

error free. ^ en ^ admowledged before frame number nine. Upon 

In an alternative embodiment, each A/N bit is set to a 30 receiving the aggregated acknowledgement indicating frame 

value of one if a corresponding numbered data segment has ten was successfully received, and also indicating frame nine 

not been transmitted or has been transmitted in error. In this was not successfully received, the transmitting entity 

alternative embodiment, each A/N bit is set to a value of zero retransmits frame nine in the following time frame, 

if the corresponding numbered data segment has been In lhis embodimentj me subsequent receipt of an aggre- 

transmitted, and received, error free. gated acknowledgement of data frame nine does not trigger 

A Supervision field 415 is stored in bits one through five retransmission of data frame ten. This is because the suc- 

of the twelfth octet of the AACK message 400. Supervision cessful transmission of data frame ten has already been 

procedures, and the corresponding Supervision field 415, are previously acknowledged; its respective bit in the aggre- 

generally used to control abnormal link conditions between ^ ga ted acknowledge messages have been set, and remains set, 

a transmitting and a receiving entity. to indicate its successful receipt by the receiving entity. 

AFlow Control field 420 is stored in bits six through eight In a mird event> when a data segment, or frame, is first 

of the twelfth octet of the AACK message 400. Flow control transmitted, a respective timer is set in the transmitting 

procedures, and the corresponding Flow Control field 420, entitVi In this embodiment, if the data segment is unacknowl- 

are generally used to monitor and control the transmit 45 edged when ^ ^ expires, i.e., the transmitting entity 

window size. does not receive an aggregated acknowledgement acknowl- 

Spare bits 425 comprise octets thirteen through twenty of edging the data segment before its respective timer expires, 

the AACK message 400. In an embodiment, additional error the transmitting entity retransmits the data segment. In this 

detection CRC is implemented in one or more of the spare embodiment, as with the others, the aggregated acknowl- 

bits 425, to reduce the chance of undetected errors in the 5Q edgement message acknowledging the retransmitted data 

AACK message 400. segment does not trigger retransmission of data segments 

Generally, at the time an AACK message 400 is composed that have been successfully transmitted, and received, 

for transmission, all data segments of a packet that have In a presently preferred embodiment of this third event, 

been correctly received are acknowledged by the receiving the data segment, or frame, associated with the timer expiry, 

end, or entity. In a presently preferred embodiment, this is 55 the data segment whose respective timer expired before 

done by setting the A/N bit in the AACK message 400 a n acknowledgment of its transmission is received by the 

corresponding to the sequence number of each successfully transmitting entity, is retransmitted once all the data seg- 

transmitted data segment of a packet to a value of one. ments 0 f fo c respective data packet are transmitted at least 

When the AACK message 400 is received by the entity once, in sequential order. In an alternative embodiment, the 

transmitting the packet, all successfully acknowledged data ^ data segment, or frame, associated with the timer expiry is 

segments can be discarded, or otherwise ignored. retransmitted in the time frame following the time frame in 

The entity transmitting the packet, under certain which its respective timer expires, 

circumstances, can be triggered to retransmit one or more In FIG. 8, an exemplary packet transmission scenario 465 

data segments, or frames, of a packet data. It is envisioned of a packet of 2129-2280 bits is depicted. In scenario 465, 

that three such events may trigger retransmissions. 65 every data segment transmission is successfully transmitted, 

An AACK message is generally transmitted to acknowl- and received, on a first transmission attempt As previously 

edge one or more transmitted data segments. In some indicated, in a presently preferred embodiment, each data 
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segment contains a maximum of nineteen octets of data, or 
one hundred and fifty-two (152) bits. Thus, a packet of 
between 2129 and 2280 bits requires fifteen data segments 
to transmit completely. In exemplary transmission scenario 
465, five data segments are transmitted per time frame, and 5 
one AACK message is also transmitted per time frame. 
Thus, the entity transmitting the packet uses five time slots 
per time frame and the receiving entity uses one time slot per 
time frame. 

In scenario 465, a first group of five data segments 451 is 10 
successfully transmitted in a first time frame 450. This first 
group 451 contains data segments with sequence numbers 
one through five. The receiving entity, after receiving the 
five data segments 451, transmits an AACK message 452, 
indicating that all of them were successfully transmitted. 15 

Hie AACK message 452, generally depicted in FIG. 9 A, 
has the first five bits of its bit map 485 set to a value of one. 
Specifically, bits one through five of the second octet 480 of 
AACK message 452 are each set to a value of one, indicating 
that data segments one through five respectively were sue- 20 
cessfully transmitted. 

Referring again to FIG. 8, in time frame 455 of scenario 
465, a second group of five data segments 453 is success- 
fully transmitted. This second group 453 contains data 
segments with sequence numbers six through ten. The 25 
receiving entity, after receiving the five data segments 453, 
transmits an AACK message 454, indicating that all of them 
were successfully transmitted. 

The AACK message 454, generally depicted in FIG. 9B, ^ 
has the first ten bits of its bit map 486 set to a value of one. 
Specifically, bits six through eight of the second octet 481 
and bits one and two of the third octet 482 of AACK 
message 454 are each set to a value of one, indicating that 
data segments six through ten respectively were successfully 35 
transmitted. Further, bits one through five of the second octet 
481 are also each set to a value of one, as a continuing 
indication that data segments one through five, which were 
previously transmitted, were also successfully transmitted. 

Referring once again to FIG. 8, in time frame 460 of 40 
scenario 465, the third, and final, group of five data segments 
456 is successfully transmitted. This last group 456 contains 
data segments with sequence numbers eleven through fif- 
teen. The receiving entity, after receiving the five data 
segments 456, transmits an AACK message 457, indicating 45 
that all of them were successfully transmitted. 

The AACK message 457, generally depicted in FIG. 9C, 
has the first fifteen bits of its bit map 487 set to a value of 
one. Specifically, bits three through seven of the third octet 
484 of AACK message 457 are each set to a value of one, 50 
indicating that data segments eleven through fifteen respec- 
tively were successfully transmitted. Further, bits one 
through eight of the second octet 483 and bits one and two 
of the third octet 484 are also each set to a value of one, as 
a continuing indication that data segments one through ten, 55 
which were previously transmitted, were also successfully 
transmitted. 

In a presently preferred embodiment, the receiving entity 
transmits an AACK message whenever it receives the final 
data segment of a packet. In a presently preferred 60 
embodiment, the receiving entity knows that it has received 
the final data segment of a packet by use of a bit in the data 
segment messages. A single bit (a "More bit") of each data 
segment of a packet is implemented to indicate whether or 
not there are more data segments of the packet to be 65 
transmitted. In a presently preferred embodiment, the More 
bit is set to a value of one if there are more data segments 
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in the packet to be transmitted, and set to a value of zero if 
the More bit is in the last data segment of the packet. In an 
alternative embodiment, the More bit of a data segment is set 
to a value of zero if there are more data segments in the 
packet to be transmitted, and set to a value of one if the More 
bit is in the last data segment of the packet. 

Additionally, other alternative schemes for indicating the 
total number of data segments in a packet may be imple- 
mented. For example, the number of data segments in the 
packet to be transmitted may be indicated during the pro- 
cessing of a transmission resource allocation procedure, 
when resources, such as, e.g., time slots, are allocated to 
establish a transmission link between a transmitting and a 
receiving entity. In this scheme, the number of data segments 
is forwarded from the transmitting entity to the receiving 
entity as part of the resource allocation procedure. As a 
further example, the number of data segments in the packet 
to be transmitted may be included as a field in the first data 
segment transmitted, or in each data segment transmitted. 

In FIG. 10, an exemplary packet transmission scenario 
501 of a packet of 2129-2280 bits is depicted. In scenario 
501, various data segments are unsuccessfully transmitted 
on the first attempt. As previously indicated, in a presently 
preferred embodiment, each data segment comprises a maxi- 
mum of one hundred and fifty two (152) bits of data, and, 
therefore, a packet of between 2129 and 2280 bits requires 
fifteen data segments to transmit completely. In scenario 
501, five data segments are transmitted per time frame, and 
one AACK message is also transmitted per time frame. 

In scenario 501, a first group of five data segments 502 is 
transmitted in a first time frame 503. This first group 502 
contains data segments with sequence numbers one through 
five. In this first group 502, however, the second data 
segment 511, the fourth data segment 513 and the fifth data 
segment 514 are each unsuccessfully transmitted. 

The receiving entity, in the appropriate time slot, and after 
successfully receiving the first data segment 510 and the 
third data segment 512, transmits an AACK message 515, 
indicating that data segments 510 and 512 were successfully 
transmitted. The AACK message 515, generally depicted in 
FIG. 11 A, has the first A/N bit 550 and the third A/N bit 551 
of its bit map 590 set to a value of one. Specifically, bits one 
and three of the second octet 556 of AACK message 515 are 
each set to a value of one, indicating that data segments one 
and three respectively were successfully transmitted. No 
other A/N bits in AACK message 515 are set to a value of 
one as the receiving entity did not successfully receive any 
other data segments in the packet. Thus, bits 552, 553 and 
554 of AACK message 515 are set to a value of zero, as the 
receiving entity did not successfully receive the second, 
forth and fifth data segments of the packet, even though the 
transmitting entity transmitted them. 

Referring again to FIG. 10, in a second time frame 504, 
the transmitting entity transmits a second group 534 of five 
data segments. The second group 534 comprises data seg- 
ments with sequence numbers six through ten. In this second 
group 534, the seventh data frame 517 and the tenth data 
frame 520 are both unsuccessfully transmitted; the sixth data 
frame 516, the eighth data frame 518 and the ninth data 
frame 519 are, however, successfully transmitted at this 
time. 

The receiving entity, in the appropriate time slot, and after 
successfully receiving the sixth data segment 516, the eighth 
data segment 518 and the ninth data segment 519, transmits 
an AACK message 521, indicating that data segments 516, 
518 and 519 were successfully transmitted. The AACK 
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message 521, generally depicted in FIG. 11B, has the sixth, segments. Hie fourth group 536 comprises data segments 

eighth and ninth A/N bits of its bit map 595 set to a value of with sequence numbers two, four, five, seven and ten; i.e., all 

one. Specifically, bits six and eight of the second octet 555 of the data segments that were previously unsuccessfully 

and bit one of the third octet 557 of AACK message 521 are transmitted. In this fourth group 536, all the data segments 

each set to a value of one, indicating that data segments six, 5 axe successfully transmitted at this time, 

eight and nine respectively were successfully transmitted. The receiving entity, in the appropriate time slot, and after 

Further, bits one and three of the second octet 555 are also successfully receiving the second, fourth, fifth, seventh and 

each set to a value of one, as a continuing indication that data tenth data segments, 528-532 respectively, transmits an 

segments one and three, which were previously transmitted, AACK message 533, indicating that data segments 528 

were also successfully transmitted. io through 532 were successfully transmitted. The AACK 

No other A/N bits in AACK message 521 are set to a value message 533, generally depicted in FIG. 11D, has the 

of one as the receiving entity did not successfully receive second, fourth, fifth, seventh and tenth A/N bits of its bit map 

any other data segments in the packet. Thus, bits two, four, 605 set to a value of one. Specifically, bits two, four, five and 

five and seven of the second octet 555 and bit two of the seven of the second octet 580 and bit two of the third octet 

third octet 557 remain set to zero, as the receiving entity did 15 581 of AACK message 533 are each set to a value of one, 

not successfully receive the second, fourth, fifth, seventh or indicating that data segments two, four, five, seven and ten 

tenth data segments of the packet at this time, even though respectively were successfully transmitted. Further, bits one, 

the transmitting entity transmitted them. three, six and eight of the second octet 580 and bits one and 

Referring again to FIG. 10, in a third time frame 505, the three through seven of the third octet 581 are also each set 

transmitting entity transmits a third group 535 of five data 20 to a value of one, as a continuing indication that data 

segments. The third group 535 comprises data segments segments one, three, six, eight, nine, and eleven through 

with sequence numbers eleven through fifteen. In this third fifteen, which were previously transmitted, were also suc- 

group 535, all the data segments eleven through fifteen are cessfully transmitted. 

successfully transmitted at this time. No other A/N bits in the bit map 605 of AACK message 

The receiving entity, in the appropriate time slot, and after 25 533 are set to a value of one as the transmitting entity did not 

successfully receiving the eleventh through fifteenth data transmit any other data segments. Thus, by the end of the 

segments, 522-526 respectively, transmits an AACK mes- fourth time frame 506, the packet has been successfully 

sage 527, indicating that data segments 522 through 526 transmitted by the transmitting entity and acknowledged by 

were successfully transmitted. The AACK message 527, ^ the receiving entity. 

generally depicted in FIG, 11C, has the eleventh, twelfth, In scenario 501, if there were only fourteen data 

thirteenth, fourteenth and fifteenth A/N bits of its bit map segments, for example, comprising the packet to be 

600 set to a value of one. Specifically, bits three through transmitted, then in time frame 505, only four data segments 

seven of the third octet 563 of AACK message 527 are each would be required to be transmitted for the first time, i.e., 

set to a value of one, indicating that data segments eleven 3S data segments eleven through fourteen. As in scenario 501 

through fifteen respectively were successfully transmitted. five data segments are sent per time frame, this would leave 

Further, bits one, three, six and eight of the second octet 562 one time slot available for the beginning of any necessary 

and bit one of the third octet 563 are also each set to a value retransmissions. In a presently preferred embodiment and in 

of one, as a continuing indication that data segments one, exemplary scenario 501, in this situation, the transmitting 

three, six, eight and nine, which were previously ^ entity transmits the second data segment as part of the third 

transmitted, were also successfully transmitted. group of data segments. Referring to FIG. 12, in time frame 

No other A/N bits in AACK message 527 are set to a value 505, a third group 620 of five data segments comprise data 

of one as the receiving entity did not successfully receive segments eleven through fourteen, 522-525 respectively, 

any other data segments in the packet. Thus, bits two, four, and the retransmission of the second data segment 621. 

five and seven of the second octet 562 and bit two of the 45 In scenario 630, all five data segments in group 620 are 

third octet 563 remain set to zero, as the receiving entity did successfully transmitted. Thus, the receiving entity transmits 

not successfully receive the second, fourth, fifth, seventh or an AACK message 622 to the transmitting entity, indicating 

tenth data segments of the packet at this time, even though that data segments two and eleven through fourteen have 

the transmitting entity previously transmitted them. been successfully transmitted. In scenario 630, which is 

The transmitting entity has now transmitted every data so identical to scenario 501 of FIG. 10 until the third time frame 

segment in the fifteen data segment packet once. However, 505, the AACK message 622 also indicates the prior suc- 

data segments two, four, five, seven and ten have not been cessful transmission of data segments one, three, six, eight 

successfully transmitted to, or received by, the receiving and nine. 

entity. The transmitting entity is made aware that these data In scenario 630, in a fourth time frame 506, the transmit- 
segments have not been successfully transmitted by the 55 ting entity retransmits data segments four 623, five 624, 
AACK messages, 515, 521 and 527 that it has received from seven 625 and ten 626 . As in scenario 630 five data segments 
the receiving entity. Thus, at this time, the transmitting entity are sent per time frame, this leaves one time slot available 
begins retransmitting the data segments that were previously for a data segment transmission. In a presently preferred 
transmitted in error. In a presently preferred embodiment, embodiment, in this situation, the transmitting entity retrans- 
the transmitting entity retransmits the data segments in 50 mits one of the four data segments, i.e., one of data segments 
sequential order. In an alternative embodiment, the trans- four, five, seven and ten, a second time in time frame 506. 
mitting entity retransmits the data segments in reverse In this manner, there is an increased chance of the doubly- 
sequential order. In yet another alternative embodiment, the transmitted data segment being successfully received by the 
transmitting entity retransmits the data segments in a gen- receiving entity. 

erally random order. 6S i n a presently preferred embodiment, the transmitting 

Referring again to FIG. 10, in a fourth time frame 506, the entity retransmits the lowest sequentially numbered data 

transmitting entity transmits a fourth group 536 of five data segment twice, e.g., for example, in scenario 630, data 



05/10/2004, EAST Version: 1.4.1 



US 6,301,249 Bl 
17 18 

segment four 627 is retransmitted twice. In an alternative network 652. Urns, a BTS is responsible for the physical 

embodiment, the transmitting entity retransmits the highest communication link for end users to gain access to the 

sequentially numbered data segment twice, e.g., for wireless network 670. 

example, in scenario 630 data segment ten would be trans- j n general, an NSS of a packet data service provider 
mitted twice in group 629. In yet another alternative 5 network 652 is a collection of network elements that pro- 
embodiment, the transmitting entity retransmits a generally v ides switching and interconnectivity support for the wire- 
random data segment that requires retransmission twice, \ css network 670. 

e.g., for example, in scenario 630 any of data segments four, In a nt]y p re ferred embodiment, the packet data 

five, seven or ten could be retransmitted twice in group 629. services network 650 is connected, via an external network 

In a presently preferred embodiment, if one or more data 10 mterface 662> to one or more external packet data networks 

segments have been unsuccessfully retransmitted two or 6 56. The external packet data networks 656 are networks 

more times, the data segments) with the highest retrans- mat are external to the packet data services network 650. An 

mission failure rate is retransmitted in the extra transmission example of an external packet data network 656 is the 

time slot(s) of a time frame. Internet. In a presently preferred embodiment, the external 

In a presently preferred embodiment, if more than one 15 network interface 662 is a landline interface, and thus, 

time slot is available in a time frame for the retransmission provides a wireline interface between the packet data ser- 

of data segments after all data segments to be retransmitted vices network 650 and an external packet data network 656. 

have been accommodated for in the time frame, one or more 0ne or more mobile end stations 654 communicate with 

of the data segments to be retransmitted is retransmitted me packet data services network 650. A mobile end station 

more than once. For example, in scenario 630, if only data 20 (« MES ») 654 & generally an end user of the wireless 

segment four required retransmission in time frame 506, ne twork system 670. In a presently preferred embodiment, 

then data segment four would be transmitted five times, in m MES ^ a lermina i un it. In an alternative embodiment, an 

each of the five available time slots, in time frame 506. MES can comprise a fixed terminal. An MES 654 can 

As another example, in scenario 630 if only data segments negotiate for and acquire a physical communication con- 
four and five required retransmission in time frame 506, then nection with a packet data service provider network 652 via 
data segment four may be transmitted in three time slots and an over-the-air ("OP"), i.e., wireless or radio, mterface 658. 
data segment five may be transmitted in two time slots of Generally, the OP interface is the physical transmission 
time frame 506. Alternatively, in this scenario of only data interface, or link, between the MES 654 and a wireless 
segments four and five requiring retransmission in time ^ packet data service provider network 652. 
frame 506 of scenario 630, data segment four may be In a presently prcferred embodiment, an MES 654 has a 
transmitted two times and data segment five may be trans- mobilc sUtion ( « MS „ )( a data termmal ad tCf ^ OTA «) and 
mitted three times in time frame 506. Other various permu- data tcrminal equipment ("DTE"). The MS provides the 
tations of the transmission schedules for data segments four communication interface, over-the-air, between the MES 
and five are also conceivable, and remain within the scope ^ 654 ^ a packct data scrvke provider nctwofk 652 

of the inventions herein. In one embodiment, referring to FIG. 14A, the DTE 701, 

In another embodiment, the frequency of the AACK ^ DTA702 ^ ^ MS ?03 are h icall ate uni(s 

message transmissions is determined as part of a transmis- m ^ MES 700 In one le of ^ embodiment> the 

sion resource allocation procedure. For example, an AACK DJA 702 resideg mside ^ DJR 701 m ^ form of a data 

message may be sent every second time frame or every ^ terminal ^ card ]n a u fcrred 

fourth time frame. In this embodiment, the number of new embodiment me DTE 701 is a personal computer ("PC) 

acknowledgements of data segment transmissions in each ^ ±c DTE ^ fe a pc cafd Iq ±[s } ^ Dm702 

AACK message is determined by the window size of the tQ ^ MS ?03 b a ^ [q k Qf 

packet transmission and the frequency of the AACK mes- ^ embodimenl( me DTA7 02 ^ a sep arate unit on a cable 

sage transmission. 45 mat ^ MS 703 t0 a DTE RS-232 port. 

In a presently preferred embodiment, the aggregated 1q ^ MES 70Q 6 ^ 1Q4 ^ bctw£en ^ DJ£ 

acknowledgement mechanism is used in a wireless network, ^ ^ DTA?()2 and ^ mfonnation 715 

° f f y w^^T ^y?^^ b0 ^f^^ is passed between the DTA702 and the MS 703. 
network 670, as shown in FIG. 13, a packet data services 

network 650 is a wireless and mobile extension of known 50 In ""^ embodiment of an MES 705, referring to FIG. 

data networks. Packet data services network 650 provides 14B > to MS 706 ^ D1A 707 are incorporated into a 

seamless access capability to applications that are generally sm S le Physical unit, while the DTE 709 remains a separate 

provided over wireline data networks. unit In tnis embodiment, the combined MS 706 and DTA 

A i * j j • > i . M f 707 connect to, and, thereby transfer data 708 to and from 

A packet data services network 650 is a collection of ~_ . . _* ~™ _„ n T 

i * , . . , ™ . . , . the DTE 709 via a senal port on the DTE 709. In a presently 

packet data service provider networks 652. The packet data ss * j , „ .f ^— - AA 

* . . , f . * j * u *u preferred embodiment, the DTE 709 is a PC. 

service provider networks 652 are connected to each other r 1 

via an internal network interface 660. In vet a* 0 *" embodiment of an MES 710, referring to 

In a presently preferred embodiment, each packet data ™3. 14C > * c MS 711, the DTA 712 and the DTE 713 are 

service provider network 652 has a base station subsystem ^ ™orporated into a single physical unit. 

("BSS") and a network switching subsystem ("NSS"). In 60 In each of the embodiments of an MES (700, 705 and 710 

general, a BSS provides wireless transmission capabilities of FIGS. 14A, 14B and 14C respectively), data is transmit- 

and access. In a presently preferred embodiment, a BSS has te d out 721 of the MS to a packet data services network 720 

one or more base transceiver stations ("BTS"s) and a base *n d is received into 722 the MS from the packet data 

station controller ("BSC). In an alternative embodiment, a services network 720. 

BSS may have more than one BSC. A BTS is responsible for 65 Referring again to FIG. 13, a packet data services network 

managing the over-the-air resources between an end user of 650 provides a standard Internet Protocol ("LP") network 

the wireless network 670 and a packet data service provider layer service, and, therefore, generally all of the applications 
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over the Internet are available via the packet data services 
network 650. Further, a packet data services network 650 
enables an MES 654 to transmit and receive data to and from 
other entities, for example, e.g., external packet data net- 
works 656 and/or other MESs 654, connected to the packet 
data services network 650. An MES 654 is an endpoint of 
communication in the wireless network 670, and, therefore, 
each MES 654 is a potential source and destination of 
network traffic, i.e., user messages. 

In an embodiment, the entity transmitting packets is a 
BTS and the entity receiving packets is an MES. In another 
embodiment, the entity transmitting packets is an MES and 
the entity receiving packets is a BTS. In a presently pre- 
ferred embodiment, both the MESs and the BTSs have a 
processor and associated memory for executing respective 
software instructions to accomplish the above-described 
aggregated acknowledgment mechanism. 

Referring to FIG. 15, a presently preferred embodiment of 
a protocol stack for an MES and a presently preferred 
embodiment of a protocol stack for a base station subsystem 
("BSS"), the protocol stacks generally describing protocol 
processing layers, is defined for the conveyance of 
information, e.g., messages, between a BTS and an MES. In 
the MES protocol stack 720, the sub-network dependent 
convergence protocol ("SNDCP") layer 722 can be viewed 
as a layer of the logical link control ("IXC") protocol layer 
724. The SNDCP layer 722 provides mapping of Layer 3 
Internet Protocol ("IP") packets onto LLC frames for trans- 
mission within a packet data services network. The SNDCP 
layer 722 provides data encryption, IP header compression 
and, in an embodiment, overall data compression. 

The LLC protocol layer 724 of the MES protocol stack 
720 provides a bi-directional, reliable logical link between 
the MES and a packet data service provider network. The 
LLC protocol layer 724 incorporates framing, addressing 
and flow control. 

The media access control ("MAC")/radio link control 
("RLC") protocol layer 726 of the MES protocol stack 720 
provides access to and a link on the over-the-air interface 
between the MES and a BTS. More specifically, the RLC 
protocol provides a reliable link on the over-the-air interface 
and, further, supports the aggregated acknowledgement 
mechanism and procedures previously described. The MAC 
protocol, for its part, is responsible for access control of the 
MES to the over-the-air interface of a BTS, and comprises 
the radio resource control algorithms. 

The physical protocol layer 728 of the MES protocol 
stack 720 provides the physical interface control for trans- 
mission between the MES and a BTS. In a presently 
preferred embodiment, the physical protocol layer 728 uses 
the IS-661 radio technology. 

As with the physical protocol layer 728 in the MES 
protocol stack 720, the physical protocol layer 736 in the 
BSS protocol stack 730 provides the physical interface 
control for transmission between the respective BTS and an 
MES. In a presently preferred embodiment, the physical 
protocol layer 736 uses the IS-661 radio technology. 

The media access control ("MAC")/radio link control 
("RLC) protocol layer 734 of the BSS protocol stack 730 
provides access to and a link on the over-the-air interface 
between the respective BTS and an MES. More specifically, 
the RLC protocol provides a reliable link on the over-the-air 
interface, and, further, supports the aggregated acknowl- 
edgement mechanism and procedures previously described. 
The MAC protocol, for its part, is responsible for the control 
of access of MESs to the respective BTS's over-the-air 
interface, and comprises the radio resource control algo- 
rithms. 
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The LLC relay protocol layer 732 of the BSS protocol 
stack 730 generally provides the relay of logical link frames 
within a packet data service provider network. 

While embodiments are disclosed herein, many variations 
5 are possible which remain within the spirit and scope of the 
invention. Such variations are clear upon inspection of the 
specification, drawings and claims herein. The invention 
therefore is not to be restricted except by the scope of the 
appended claims. 
10 What is claimed is as follows: 

1. A method of transmission error control, comprising: 
transmitting at least one frame of packet data to a receiv- 
ing entity during each of a plurality of time frames, 
each time frame comprising more than one time slot; 

receiving a plurality of responsive messages from said 
receiving entity, each of said responsive messages 
operable to identify a plurality of frames of data 
successfully received or unsuccessfully received during 
a current time frame and during prior time frames; and 
retransmitting each of said frames of data that said 
responsive message indicates as unsuccessfully 
received, at least one of the frames of data identified as 
unsuccessfully received being retransmitted in more 
than one time slot of a time frame. 

2. The method of transmission error control of claim 1, 
wherein each of said responsive messages comprises a bit 
map, said bit map comprising a bit for each of said frames 
of said packet data. 

30 3. The method of transmission error control of claim 2, 
wherein a bit of said bit map corresponding to a frame of 
said packet data is set to a value of one if said frame is 
successfully received by said receiving entity. 

4. The method of transmission error control of claim 2, 
35 wherein a bit of said bit map corresponding to a frame of 

said packet data is set to a value of zero if said frame is not 
successfully received by said receiving entity. 

5. The method of error control of claim 1, wherein said 
frames of packet data are transmitted on a wireless trans- 

^ mission interface and said plurality of responsive messages 
are received on said wireless transmission interface. 

6. A method of transmission error control, comprising: 
attempting to receive at least one frame of packet data 

from a transmitting entity during each of a plurality of 
4S time frames, each time frame comprising more than 
one time slot; 

generating a responsive message after each of a plurality 
of the time frames, each of said responsive messages 
operable to identify a plurality of frames of data 
50 successfully received or unsuccessfully received during 
a current time frame and during prior time frames; 

transmitting said responsive message to said transmitting 
entity; and 

receiving at least one of the frames of data identified as 
55 unsuccessfully received, the frame of data being 
retransmitted by the transmitting entity in more than 
one time slot of a time frame. 

7. The method of transmission error control of claim 6, 
wherein said responsive message is transmitted to said 

60 transmitting entity in the same time frame as said attempt to 
receive at least one frame of packet data. 

8. The method of transmission error control of claim 6, 
wherein said responsive message comprises a bit map of bits 
and each bit of said bit map corresponds to a frame of said 

65 packet data. 

9. The method of transmission error control of claim 8, 
wherein each bit in said bit map corresponding to a received 
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frame of data is set to a value of one, prior to the transmis- 
sion of said responsive message to said transmitting entity. 

10. The method of transmission error control of claim 8, 
wherein a bit in said bit map of a first responsive message 
is set to a value of one to indicate a frame of data was 
received in a first time frame, and said first responsive 
message is transmitted in said first time frame, and said bit 
in said bit map of a second responsive message is set to a 
value of one, and said second responsive message is trans- 
mitted in a second time frame. 

11. The method of transmission error control of claim 6, 
wherein said frames of data are received on a wireless 
transmission interface and said responsive message is trans- 
mitted on said wireless transmission interface. 

12. An aggregated acknowledgment message, compris- 
ing: 

a message identification field; and 

a bit map comprising a plurality of bits, each bit having 
a first state and a second state, the first state indicating 
that a receiving entity successfully received a frame of 
data corresponding with the bit during a current time 
frame or during prior time frames, the second state 
indicating that the receiving entity did not successfully 
receive the frame of data corresponding with the bit 
during the current and prior time frames, the bit map 
operable to identify a plurality of frames of data 
successfully received or unsuccessfully received, at 
least one of the successfully received frames of data 
having been retransmitted by a transmitting entity in 
more than one time slot of a time frame. 

13. The aggregated acknowledgment message of claim 
12, wherein a bit of said bit map is set to a value of one if 
the corresponding frame of data is received by a receiving 
entity. 

14. The aggregated acknowledgment message of claim 
12, wherein said bit map is comprised of a number of bits 
corresponding to the maximum number of frames of packet 
data to be transmitted in a wireless communication system. 

15. The aggregated acknowledgement message of claim 
14, wherein said maximum number of frames is seventy- 
nine. 

16. A system for transmission error control, comprising: 
at least one computer readable medium; and 
software encoded on the at least one computer readable 

medium and operable when executed by a processor to: 

transmit at least one frame of packet data to a receiving 
entity during each of a plurality of time frames, each 
time frame comprising more than one time slot; 

receive a responsive message from the receiving entity, 
the responsive message operable to identify a plu- 
rality of frames of data successfully received or 
unsuccessfully received during a current time frame 
and during at least one prior time frame; and 

retransmit at least one of the frames of data identified 
as unsuccessfully received in more than one time slot 
of a time frame. 

17. A system for transmission error control, comprising: 
a memory operable to store a plurality of frames of packet 

data; and 
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a processor coupled to the memory and operable to: 
transmit at least one of the frames of packet data to a 
receiving entity during each of a plurality of time 
frames, each time frame comprising more than one 
time slot; 

receive a responsive message from the receiving entity, 
the responsive message operable to identify a plu- 
rality of frames of data successfully received or 
unsuccessfully received during a current time frame 
and during at least one prior time frame; and 

retransmit at least one of the frames of data identified 
as unsuccessfully received in more than one time slot 
of a time frame. 

18. A system for transmission error control, comprising: 
at least one computer readable medium; and 
software encoded on the at least one computer readable 

medium and operable when executed by a processor to: 

attempt to receive at least one frame of packet data 
from a transmitting entity during each of a plurality 
of time frames, each time frame comprising more 
than one time slot; 

generate at least one responsive message operable to 
identify a plurality of frames of data successfully 
received or unsuccessfully received during a current 
time frame and during at least one prior time frame; 

transmit the responsive message to the transmitting 
entity; and 

receive at least one of the frames of data identified as 
unsuccessfully received, the frame of data being 
retransmitted by the transmitting entity in more than 
one time slot of a time frame. 

19. A system for transmission error control, comprising: 
a memory operable to store a bit map, the bit map 

comprising a plurality of bits and being operable to 
identify a plurality of frames of data successfully 
received or unsuccessfully received; and 
a processor coupled to the memory and operable to: 
attempt to receive at least one frame of packet data 
from a transmitting entity during each of a plurality 
of time frames, each time frame comprising more 
than one time slot; 
set at least one of the bits in the bit map to a first state 
or a second state, the first state indicating that a 
frame of data was successfully received during a 
current time frame or during a prior time frame, the 
second state indicating that the frame of data was 
unsuccessfully received during the current and prior 
time frames; 

generate at least one responsive message using the bit 
map; 

transmit the responsive message to the transmitting 
entity; and 

receive at least one of the frames of data identified as 
unsuccessfully received, the frame of data being 
retransmitted by the transmitting entity in more than 
one time slot of a time frame. 
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